Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > разработка игр, графический дизайн и моделирование > Gamedev - cоздание игр: Unity, OpenGL, DirectX
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 02.07.2013, 10:23   #11
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

План работы

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

Итак, концептуально план работы над данным моим проектом представляет собой следующее (с учетом некоторых важных поправок, о которых ниже):
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 02.07.2013, 10:24   #12
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

1. Постановка задачи. Для начала нужно четко определиться, что мы хотим получить результатом своей работы. По сути, это самый важный пункт, поскольку решения, принятые на этом этапе, будут иметь определяющее значение на все, что будет происходить в дальнейшем. Начиная с самых общих идей, через их конкретизацию мы придем к составлению вполне конкретных документов, в которых будет четко зафиксирован будущий облик нашей игры. Говоря упрощенно, после этого останется только реализовать то, что будет уже придумано. Говоря же более строго, в дальнейшем каждый последующий этап будет все менее и менее творческим и все более и более техническим. Насколько - обязательно смотрите чуть ниже!

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

3. Проектирование. Имея перед собой четко поставленную задачу, и определившись с набором инструментов, мы начинаем эту задачу решать. Однако, мы вовсе не беремся сразу же что-то программировать. Прежде нам нужно построить структуру будущего приложения - разбить его на составляющие элементы и определить, как они друг с другом соотносятся. На самом деле, это по-прежнему еще очень творческий этап, хотя тут и начинают уже проявляться технические моменты. Надеюсь, я не удивлю вас, сказав, что этот этап самый важный после постановки задачи - ведь на этой стадии также закладываются те отношения, которые будут играть определяющую роль в дальнейшей работе. Составив четкую схему приложения, нам нужно будет только реализовать отдельные ее элементы и обеспечить необходимые взаимосвязи между ними. Опять же, упрощенно говоря.

4. Создание кода. Этот пункт включает в себя весь обширный процесс воплощения составленного проекта в программный код. Помимо собственно игры я планирую разработать некоторое количество сопутствующего инструментария (главным образом - редактор карт). Как бы ни было обидно, но в некотором отношении этот этап будет проходным - результат его выполнения не будет оказывать определяющего влияния на финальный облик игры. Структура ее определяется проектом, внешний вид - дизайном и контентом, а код - это рабочая прослойка между ними. Примерно как мышцы, являющиеся рабочей прослойкой между скелетом и кожей. Но, само собой, на этом этапе нельзя расслабляться - ошибки, сделанные здесь, могут также оказать роковое влияние на конечный результат.

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

6. Финализация проекта. Найдя необходимых нам специалистов, мы переходим к созданию игрового контента - графики, игровых уровней, музыки, фоновых звуков и т.п. Пусть только вас не обманывает слово "финализация", создавая у вас иллюзию, будто она займет лишь пару дней. Просто я не подобрал более подходящего слова для описания всего обширного процесса превращения игрового движка в конечный игровой продукт. Здесь мы постараемся максимально эффективно обыграть все технические возможности, заложенные в программный код, чтобы создать максимально приятный и увлекательный геймплей. Кстати, на этом этапе срезаются многие разработчики игр. Помимо создания новых вещей (дизайна, сюжета, контента) здесь мы занимаемся доводкой старых - доводим до ума программный код, структуру интерфейса, параметры геймплея (ИИ, игровой баланс, экономику при ее наличии, некоторые неглобальные фичи и другое). Также здесь очень важна координация усилий всей команды, что позволит в разумные сроки создать качественную и цельную игру.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 02.07.2013, 10:28   #13
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Замечания

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

Кроме того, пункт Выбор инструментов может быть выполнен к окончанию пункта Постановка задачи и, по крайней мере, частично найдет свое отражение в составленных в этом пункте документах.

Также замечу, что данный план в общих чертах верен в ситуации, когда проект начинается с одного программиста, который затем по мере насущной необходимости собирает команду. В уже сформировавшемся коллективе уже после постановки задачи в более или менее конкретной форме может начинаться работа ролей не только программиста, но и художника (составление концепт-арта), дизайнера уровней, писателя (создание игрового мира и сюжетной линии) и, возможно, других. (Говоря о ролях, я хочу подчеркнуть, что "один человек" != "одна функция", в небольших проектах один член команды может выполнять несколько видов работ, в больших - одну функцию могут совместно выполнять несколько участников, причем количество занятых людей будет варьироваться в зависимости от этапа развития проекта).

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

Более подробный разбор пунктов данного плана будет приведен в следующих постах.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 02.07.2013, 23:04   #14
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

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

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

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

Одним словом, этот проект изначально представлял собой техническое переосмысление некоторых аспектов "Операции Погостъ". Я начинал с представления о том, как я буду реализовывать те или иные возможности игры, а также что нового в плане геймплея эти возможности могут ему дать. Достаточно сказать, что над сюжетом и сеттингом я впервые задумался только вчера!

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

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

Итак, с самого начала работы над проектом в него вкралась серьезная ошибка, но благодаря правильному подходу к работе ее удалось вовремя выявить и исправить, прежде чем она смогла нанести какой-то вред. Правильно составленный план работы просто вынудил обратить внимание на то, что должно быть сделано в начале, а что нужно отложить на потом.

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

Ну а чтобы не забыть все свои гениальные открытия к тому моменту, как они будут увековечены в документах, я скачал себе на телефон приложение для составления заметок и теперь постепенно вношу их туда в виде кратких тезисов. Вообще-то, это надо было сделать раньше, поскольку часть своих идей я вот так сходу не вспоминаю, но лучше поздно чем никогда. И вам советую поступать так же - записывать все свои мысли по поводу игры в какую-нибудь тетрадку, блокнот, вордовский файл или программу для заметок.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 03.07.2013, 10:24   #15
intmain
Играюсь с Python
Форумчанин
 
Аватар для intmain
 
Регистрация: 12.12.2012
Сообщений: 340
Лампочка

Цитата:
я впервые задумался только вчера!
Ну это вполне нормально, я еще и не начинал.

С одной стороны интересно, что есть первоначало ?
Т.е. например: сеттинг порождает дейсвия в игре (геймплей) или же ЖЕЛАЕМЫЕ действия в игре (те действия которые ты хотел бы видеть в ней) порождают сеттинг, вот дилема же? Покрайней мере для меня.

Цитата:
И вам советую поступать так же - записывать все свои мысли по поводу игры в какую-нибудь тетрадку, блокнот, вордовский файл или программу для заметок.
Весьма дельная мысль. У меня это правда выражено в виде кучи картинок, текстов, набросков сцен в пейнте, валлпапиров всяких ) В общем все то что позволяет не осведомленному человеку хотя бы чу чуть включится в тему происходящего.
Что ел то - в долг, что жил то - зря.
Для избранных. ))
Секретные разработки

Последний раз редактировалось intmain; 03.07.2013 в 10:30.
intmain вне форума Ответить с цитированием
Старый 04.07.2013, 06:57   #16
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Цитата:
С одной стороны интересно, что есть первоначало ?
Т.е. например: сеттинг порождает дейсвия в игре (геймплей) или же ЖЕЛАЕМЫЕ действия в игре (те действия которые ты хотел бы видеть в ней) порождают сеттинг, вот дилема же? Покрайней мере для меня.
Да в принципе и то, и то возможно. Хотя чаще сначала более-менее определяются с сеттингом, и только потом под него подгоняют конкретный геймплей. Хотя вот различные клоны делаются от противного - берут уже известный геймплей и придумывают для него новую обертку. Или если есть какая-то система правил (типа ДыНДы, ГУРПСа или подобные), которые уже половина геймплея, то для них можно сеттингов выбрать или создать великое множество.

Я в этот раз, во всяком случае, буду отталкиваться скорее от сеттинга.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 11.07.2013, 10:53   #17
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

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

Неизбежность ошибок

Как известно, ошибки есть во всех реальных приложениях, и это объективный факт. Мы можем только сказать, что в хорошо отлаженных приложениях процент ошибок приемлемо низок. В идеале они всплывают очень редко и последствия их оказываются сравнительно безвредными.

Конечно, нам хотелось бы вовсе избежать наличия ошибок, но на деле это оказывается практически невозможно. Единственный реальный способ получить абсолютно безошибочный код - это составить его точную математическую модель и затем математически же доказать, что в коде нет ошибок.

Примером может служить проект seL4, созданный австралийскими учеными из центра NICTA, представляющий собой ядро операционной системы общего назначения, отсутствие ошибок в котором было доказано с помощью специальной машинной системы доказательств (Isabelle). Согласно пресс-релизу, при проверке имеющихся 7500 строк Си-кода (сейчас их около 8700) было доказано более 10,000 промежуточных теорем в более чем 200,000 строк формального доказательства.

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

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

От чего зависят масштабы бедствия

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

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

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

Скажем, если у нас есть последовательность этапов A -> B -> C (решения на этапе C зависят от решений, принятых на этапе B, а те в свою очередь - от принятых на этапе A), то допустив ошибку на этапе A, мы вынуждены исправлять как ее, так и последствия, возникшие на этапах B и затем C. Ошибившись на этапе B, нужно исправить ошибку в B и ее последствия в C. Ошибившись в C, нужно исправить только саму ошибку.

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

Другое дело, если мы решим просто изменить ТТХ одного из монстров или текстуру главного героя. Сделать это будет очень просто, поскольку от этих действий практически ничего не зависит, кроме конечного результата, который мы увидим в игре. Немного больший объем работ придется провести, если окажется, что какой-то игровой уровень окажется слишком легким/сложным (тогда придется менять ТТХ или количество всех монстров на этом уровне) или если модель героя смотрится плохо в каком-то из ракурсов (вместе с моделью придется менять и текстуру, и, возможно, анимацию). Но все же это тоже сравнительно простые задачи.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 11.07.2013, 10:54   #18
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Что же делать?

Итак, какие практические выводы можно сделать из всего вышесказанного?

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

Пишите код так, чтобы ошибки проявлялись на как можно более раннем этапе - желательно на этапе компиляции. Для этого как можно подробнее объясняйте компилятору, чего вы хотите добиться, и какими свойствами должен обладать ваш код (к примеру, в C++ вы можете делать это с помощью ключевых слов const, explicit, применения enum-ов, запрета на использование ненужных конструкторов или operator= и т.п.), и тогда он сможет отловить многие ошибки уже во время компиляции. Статическая проверка типов также льет воду на нашу мельницу.

Если функция могла вернуть неправильный или недопустимый результат - проверяйте полученное значение (если мы не смогли открыть файл на чтение, гораздо лучше узнать об этом сразу, а не когда мы начнем работать с данными, которые должны были быть из него считаны, но оказались заполнены старыми значениями или мусором).

На самом деле, можно многое сказать по поводу выявления и обработки ошибок, не относящееся напрямую к вышеизложенному, однако я отложу это до другого случая. Главная рекомендация на сегодня - ищите и находите ошибки как можно раньше и используйте для этого все доступные средства.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Старый 11.07.2013, 13:46   #19
intmain
Играюсь с Python
Форумчанин
 
Аватар для intmain
 
Регистрация: 12.12.2012
Сообщений: 340
Лампочка

Цитата:
Один из способов это сделать - проводить тестирование как можно раньше и как можно чаще.
Значит написал я функцию движка
texture engineTextureLoadTGA(char* file)
и тут же её проверил прописав в
int main()
{
...
tex = engineTextureLoadTGA("1.tga")
...
}
поставил брейкпойнт F9 и пронаблюдал нажимая F10 что загрузка идет как нужно, все ок. Это тянет на тестирование, на частое тестирование ?)

Цитата:
Главная рекомендация на сегодня
еще можно добавить что не нужно боятся их делать, не делает ошибок только тот кто ничего не делает. Поэтому лучше их делать (и исправлять) чем ничего ни делать.
Что ел то - в долг, что жил то - зря.
Для избранных. ))
Секретные разработки
intmain вне форума Ответить с цитированием
Старый 13.07.2013, 10:40   #20
Гром
Старожил
 
Аватар для Гром
 
Регистрация: 21.03.2009
Сообщений: 2,193
По умолчанию

Ну, будем считать, что в заглавном посте неявно присутствует эпиграф "Без фанатизма!"
Цитата:
поставил брейкпойнт F9 и пронаблюдал нажимая F10 что загрузка идет как нужно, все ок. Это тянет на тестирование, на частое тестирование ?)
Зачем же сразу в отладчик лезть? У нас презумпция невиновности - пока система успешно делает вид, что работает нормально, мы ей аутопсию не устраиваем.
Вообще это не тянет на тестирование, это тянет на отладку.

А так - да, можно даже такую функцию тестировать, особенно если она самописная (если самописная - даже нужно!). Загрузить текстуру, потом попробовать нарисовать. И вот если не получается, тогда уже лезть отладчиком в ее недра.
Цитата:
еще можно добавить что не нужно боятся их делать
Особенно, если код достаточно покрывается тестами!
Тут главное тоже без фанатизма. Волков бояться - ..., но и против танка с шашкой наголо тоже не стоит. Надо всегда иметь козырь в рукаве, достаточно убойный, чтоб не бояться ошибок. Это будет идеальный вариант.
Простые и красивые программы - коды программ + учебник C++
Создание игры - взгляд изнутри - сайт проекта
Тема на форуме, посвященная ему же
Гром вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Электронно учебное пособие gloomy_jr Общие вопросы Delphi 1 23.05.2012 14:07
Создание игры::особенности коллективной разработки флеш приложений АТИКОН Gamedev - cоздание игр: Unity, OpenGL, DirectX 9 21.08.2011 19:51
Мультимедийное учебное пособие world12_tk Помощь студентам 4 21.04.2011 17:37
статья - Может-ли ПО работать быстрее или взгляд изнутри Pblog Обсуждение статей 0 27.02.2011 23:10
Электронное учебное пособие Zeibel Помощь студентам 10 31.05.2010 10:55